With the ever-increasing advancements in the field of computer technology, more and more businesses are becoming paperless. Inventories and financial records are kept on computers instead of being tediously documented on ledgers or other paper products. Inter- and intra- office communication is also becoming paperless, including for example the transfer of business cards and calendaring information. This is possible through the use of formatted transactions, the structure of which are agreed upon in advance by each party involved in the transactions. For example, if a buyer and a seller have agreed upon the structure of a particular transaction, the buyer can communicate the transaction data electronically to the seller, and the seller's computer, knowing beforehand the structure of the formatted transaction, will be able to understand and assimilate the received data.
One such method of exchanging data in the form of a formatted transaction is Electronic Data Interchange (EDI). EDI transactions can occur directly between two business parties over a communications line. EDI transactions involve three essential elements: (1) an agreed upon set of standards; (2) a means of communicating data based upon those standards; and (3) a way of incorporating or transforming the data into the system of the receiver.
The American National Standards Institute (ANSI) is the national coordinator for standards in the United States. ANSI approves standards developed primarily by trade, technical, professional, consumer, and labor organizations when evidence is presented that those affected by the standard have substantially reached a consensus regarding its provisions. In 1979, ANSI chartered a committee known as the Accredited Standards Committee (ASC) X12, to develop uniform standards for electronic interchange of business transactions (EDI transactions). The goal of ASC X12 was to structure standards so that computer programs can translate data to or from an EDI transaction without extensive reprogramming.
ASC X12 came up with the X12 Standards for Electronic Data Interchange published in December of 1990 as Draft Version 3, Release 1, (Document Number ASC X12S/90-850). It will be appreciated by those of skill in the art that there are other types of formatted transactions in addition to X12 transactions. These include but are not limited to EDIFACT, ODETTE, and SGML transactions. A particular kind of SGML transaction utilizes the hypertext markup language (HTML) that is used extensively on the Internet.
In theory, EDI transactions offer advantages such as speed and accuracy. One potential advantage is in the area of data integration. EDI transaction data could be received and integrated with the existing business information and data processing systems of the receiving party. Thus, it would be useful to introduce the data into a format where the data can be searched and accessed at a later time, such as by integrating EDI transaction data into a database. However, conventional approaches to integrating EDI transaction data into a database are very limited.
Generally speaking, there are three basic types of databases: hierarchical, network, and relational. In relational databases, different files exist as separate relations, and therefore, there is no structure such as the owner-member structure of the hierarchical database. The relational database structure is not predetermined and relations can be added or deleted from the database schema without affecting the other relations. An additional feature of relational databases is that while hierarchical and network databases are organized to make it efficient to deal with one record at one time and to obtain a single related record at a time, relational databases are organized to efficiently deal with sets of records and to obtain a set of related records at a time.
Existing systems for integrating data into the business information or data processing system of the receiving party are often referred to as "translation systems". Some translation systems deal with EDI data but fail to integrate, store, create or describe the EDI data relationally. Other conventional approaches manipulate data retrieved from database systems but cannot generate an EDI document from such data.
Some translation methods create links between data elements in an EDI document and fields in an application database, but the field mapping or linking is constant in any given application. For example, for a particular EDI transaction, the fields of the data base are predefined or predetermined. Such methods are unable to represent optional or conditional data elements. Further, these methods do not translate the data into relational form such that data can be manipulated as structured, relational data.
Some translation methods conform input data into the output data structure in an electronic information processing system where the input and output data structures are specified in advance. For example under one method EDI formatted data is transformed into a flat file or table. However, this method suffers the disadvantage that the output data structures must be specified before the EDI transaction is processed. Thus, if the EDI transaction format changes, the engine performing the translation must be re-implemented. Further, the method does not provide a way for EDI formatted data to be transformed into a relational database and thus, the advantages of relational databases are not utilized.
Another known method includes receiving data in a first format from a source, executing a script written in a proprietary programming language to translate the data into a second format, and transmitting the data in the second format to a destination. The source and destination may be application programs and various standards of EDI transactions. This method maps data elements to a tree structure based in part on a definition assigned to that element. The method fails to map the EDI data to relations for relational database applications.
Thus, it will be appreciated that it would be an advancement in the art to provide a method for translating EDI data into relations for use in relational database applications. It would be a further advancement to provide a method of translating EDI data into a database format which preserves the context of each data element so that the EDI formatted transaction could be recreated to its original form. Such a method is disclosed and claimed herein.